Am I supposed to look on Launchpad for bugs reported against the packages I maintain in Debian?Obviously, if a bug wasn’t reported by a Debian user, it might mean nobody suffers from it, but fixing it could avoid future bug report anyway (except if this particular bug is very specific to Ubuntu). In order to improve the Debian maintainers’ work, I think it would be great that the PTS integrates the bugs in Launchpad in a simple way. This would allow us to easily subscribe to the bugs, and eventually get a notice if the bug is fixed, or at least allow us to be aware of the issue.
Agreed. This used to be a bug about this, which has been closed by Debtags more than one year ago. We now have much more useful category data for about 73% of the archive (including experimental), but what we lack is software using it. Here's a quick trick to try:
- The current sections in Synaptic are useless
/var/lib/debtags/package-tags
.role::program
,
scope::application
and interface::x11
. works-with::*
and use::*
to
navigate the results.Indeed, Xapian for example. I use it as part of the backend of the Debtags smart search, and here's our Xapian-powered normal keyword based package search interface which does stemming, indexing and all you want to ask from a serious full text index. In that page you don't see all the nice features of Xapian, but only the ones that I needed for my Debtags evil plans. Have a look at the documentation and give it a try. Here is a way to see Xapian's similarity matching in action:
- there are better keyword search technologies than strstr()
/var/lib/apt/fulltext/
, so that
various applications can share it?
gluck.debian.org
in the directory
/org/popcon.debian.org/popcon-mail/all-popcon-results
.
Ideally one can do many interesting things with this concept: besides tag
suggestions, one could identify the packages that are most representative of an
installed system, and also offer negative suggestions like: "people who have
packages like yours usually don't have this package: would you like to remove
it?".
There is more than all this that could be done. Recently, almost by accident,
I had the idea of querying packages by example, like pointing to a
file and find packages that can work with
it. I've asked
Jeroen to have
Mole collect info on all files that could
possibly get installed in /usr/lib/mime/packages/
(as suggested by Bernhard
R. Link),
to see if that prototype can be made more accurate.
Query by similarity would be nice: I don't like this program, but what else do
we have that does the same job? This is best implemented using Debtags data,
since it directly maps to semantic properties. Note that you don't have to
show a single tag to the user to implement this kind of interface. Do we have
a way to point at the X window of an application and get the name of the package
that installed it? Wouldn't it be about time to have it?
Why don't we have a system updater utility that shows the Debian
weather?
Why aren't more people playing with semantic web?
But more generally, the problem with package managers is that we seem to be
irrationally compulsive in wanting to make the one and only big easy and
complete interface for everyone. Other more reasonable
people would tell
you that if
you have two very different kinds of users you may want to consider having two
different user interfaces.
Ubuntu for example installs by default 3 package manager interfaces: Synaptic;
the thing that you access from the application menu to add applications to it;
and the update manager. Does it sound like a waste? To me it makes lots of
sense.
We have lots of interesting, usable metadata; we have algorithms; we have
prototypes; we have ideas for lots of cool, implementable features. The
question is, are we able to write applications that just combines what is
needed from all this treasure to provide the right interface(s) for our
base(s) of users?
Even if my English in 2004 wasn't easy to understand, a read
here might still be useful.
There is so much really cool stuff to be written, just within reach.
notfound 343593 4.2.26-2
nor an unversioned reopen made the
bts forget the wrong "found in 4.2.26-2".
Jeroen told me of a
heavier boot to kick the bts with:
reassigning somewhere else and back again.
This worked nicely.
Documented here, so I will be able to look it up later.
I took a look at a couple of bugs initially on Saturday: #387419 and #387498. Unfortunately, the first (kdepim FTBFS on alpha) was difficult to reproduce - the alpha machine I had available for testing was too short on memory and took a very long time to build kdepim, long enough that after 2 days I gave up. I couldn't reproduce the latter (system() hanging when running on mips) on any machine I had access to - it looks like more work is needed there... In parallel with those two RC bugs (found on Andreas' great summary page at http://bts.turmzimmer.net/details.php), I also had a very productive session working in parallel with Christian Perrier, fixing translation/i18n bugs in one of my own packages, CVS. Thanks Christian, you're a pleasure to work with! On Saturday evening, the gang of us headed into the centre of Utrecht for a nice meal, some beer and some spirited conversation at a Greek restaurant. I took the opportunity to talk with Frans Pop about some of the remaining work needed for d-i and debian-cd. On Sunday, the work continued. I was still waiting on feedback on #387498 and my build of #387419, so I decided to make the most of the uninterrupted time to get some debian-cd development work done. I'm still hoping to get multi-arch CDs working before we release etch, so this was a great help. In fact, I got so engrossed in this that I managed to work straight through dinner...! In terms of bugs, I must admit that I didn't do much in terms of reducing absolute numbers. This weekend, there were a lot of bugs in categories that don't really work well for Bug Squashing: licensing/legal bugs (which really need discussion with the maintainer), newly-opened bugs (IMHO it's a little rude to NMU a package when a bug has only just been opened - give the maintainer at least a couple of days to respond!) and deep bugs where intimate knowledge of the package is needed. I expect there will be more to work on next weekend in Zurich, if nothing else some of those "new" bugs will have aged. Early on Monday morning I caught the bus from near Jeroen's apartment to start the journey home. Thanks to the nice reliable public transport, I got all the way to Schiphol well in time. Then my flight back to Stansted was delayed... :-( It was great to meet up with a bunch of enthusiastic people. Some I'd met before (Frans, Jeroen, Hanna). Some I met for the first time (Thijs, Bas, Moritz and others). But all of them were working hard, wanting to help get Etch out on time. Let's keep up the good work! I have a small number of photos online.
Zeezichton the Grote Markt in Breda, where a number of Dutch Debian people gathered. I'm not Dutch, but I do speak Dutch, and it's always nice to meet fellow Debianistas without having to revert to English. I had a fairly entertaining chat with some people, and eventually Jeroen van Wolffelaar showed up, with whom I had some interesting talk about the state of m68k and related dak-matters. I stayed there for two hours, but they were worth it. So why did give this post a title of
Darn? When I got on the train, I broke my wristwatch. When I was taking my backpack off my back, my watch got stuck behind the strap that is supposed to keep the backpack on my back—whatever its name is—and as a result, it fell off my arm. Which isn't supposed to happen under normal conditions. It doesn't seem to be FUBAR, but it's still going to be have to be repaired before I can wear it again. I feel naked now.
Next.